Product development management involves, in part, planning, organizing, securing and managing resources to bring about the successful completion of a project with respect to specific goals and objectives. Project managers can manage resources using, for example, agile development approaches, which are characterized by factors such as relatively short time-frame intervals (often referred to as sprints or iterations), delivery of certain goals at the end of each iteration, and regular adaptation of requirements and designs in response to changing circumstances. Exemplary changes in circumstances include changes in business goals, changes driven by customer feedbacks, changes driven by improved understanding of technological challenges, changes to downstream features based on cumulative knowledge, changes in skills and resources, and changes derived from improved knowledge of estimates of work completion based on team velocity.
Under agile development approaches, a project can be organized into one or more features with each feature delivering a package of related functionalities that an end user generally expects to get all at once. In turn, each feature can be broken down into a collection of related stories with each story defining a particular functionality. For example, given a feature involving programming inline table resizing, it can be broken down into three stories—resizing columns, resizing rows and resizing the table itself. In addition, a working feature or product can be produced at the end of a release, during which the feature or product is refined through successive iterations. Typically, each iteration involves a team working through a full development cycle including the phases planning, designing and testing. Thus, agile methods minimize overall risks by allowing a project to adapt to changes quickly.
One common challenge for product development management teams using any product development approach (e.g., an agile approach) is trying to measure and compare progress made by different teams, especially when the teams are composed of different types of members and/or work on different products. Meaningful insights gathered regarding how project teams achieve results can be critical to the success of current projects as well as future projects. Typically, in an agile development approach, story points, burndown and velocity metrics can be used to measure team effectiveness. Story points refer to units of effort and can be used by a team to estimate and track work. Burndown refers to story points completed and plotted against time lapsed. The burndown has only been used by teams within and during a short time period, such as a given iteration, to visually track progress during that period. Velocity refers to the average number of story points delivered by an agile team over one or more iterations, which is important for forecasting how much work a team is able to handle. However, none of these metrics can accurately, fairly and consistently quantify team effectiveness to enable analysis of cross-team behavior (e.g., behavior of different teams staffed on different projects) to inform decision-making at the organizational level. In particular, story points and velocity (i.e., a function of story points) are specific to a given team. They represent a blend of inherent team understanding, assumptions and norms that are team specific. Hence, these metrics are inherently inefficient and inaccurate for comparing cross-team effectiveness.